Dan North 在 2003–2004 年提出 BDD（Behavior-Driven Development） 的概念。他一開始是想改善 TDD溝通太技術化的問題。但那時只是用「Given, When, Then」這種口語描述方式，還沒有正式語法。Aslak Hellesoy 在 2008 年開發 Cucumber（一個 BDD 測試框架），為了讓大家用自然語言寫測試，他設計了Gherkin這個正式的語法規範。

Gherkin 是一種結構化、簡潔的自然語言格式，用來描述軟體系統的行為。它的目的是讓業務、開發與測試人員之間能共同理解需求，並能直接用來產生可執行的驗收測試。

Gherkin 主要特色：
• 用非常自然的英文（或其他語言）撰寫。
• 使用固定的 關鍵字（Keyword) 來標示每個步驟的角色與目的。
• 強調範例驅動（Example-driven），而非單純說明。
Gherkin 的核心精神是：「用範例說清楚需求」。

常用 Keywords 說明與範例

(1). Feature
用來說明一個功能或主題。
它描述一組相關的行為或需求，是整個文件的起點。
範例：
Feature: 使用者登入
讓使用者可以安全地登入系統，並獲得個人化服務。

(2). Rule（Gherkin 6 起支援）
描述某個功能下的特定規則或業務邏輯。
可以幫助將一個 Feature 下的行為依規則區分清楚。
範例：

Feature: 使用者登入

  Rule: 密碼必須正確
    Example: 密碼正確才能登入成功
      Given 使用者在登入頁
      When 輸入正確的帳號與密碼
      Then 登入成功，進入首頁

(3). Example（或 Scenario）
描述一個具體的使用情境。
每個 Example（Scenario）就是一個可以驗證的流程。
範例：

Scenario: 正確登入
  Given 使用者在登入頁
  When 輸入正確的帳號與密碼
  Then 進入首頁

(4). Given / When / Then / And / But
這些是敘述步驟的核心關鍵字，通常組成一個流程：
• Given：描述前置條件。
• When：描述動作或事件。
• Then：描述預期結果。
• And：延續上一個步驟（可以連續列出多個）。
• But：轉折或補充意外情況。
範例：

Scenario: 帳號不存在時登入失敗
  Given 使用者在登入頁
  When 輸入錯誤的帳號與密碼
  Then 顯示「帳號或密碼錯誤」訊息
  And 留在登入頁面

(5). Background
為一組 Scenario 提供共同的前置設定。
避免每個 Scenario 都重複寫一樣的 Given。
範例：

Feature: 訂票系統

  Background:
    Given 使用者已經登入
    And 使用者已經選擇出發地與目的地

  Scenario: 成功訂票
    When 選擇日期與班次
    Then 成功完成訂票

每個 Scenario 都會先自動執行 Background 的 Given。

(6). Scenario Outline（或 Scenario Template）
描述一個模式（template），可以套用不同的資料組合。
用來避免重複寫類似但只差輸入/輸出不同的 Scenario。
範例：

Scenario Outline: 登入驗證
  Given 使用者在登入頁
  When 輸入帳號 <帳號> 與密碼 <密碼>
  Then 顯示訊息 <結果>

  Examples:
    | 帳號      | 密碼    | 結果                 |
    | user1     | pass1   | 登入成功              |
    | user2     | wrong   | 帳號或密碼錯誤        |

這裡 Scenario Outline 會根據 Examples 表格跑兩組不同的測試案例。

(7). Examples（或 Scenarios）
Scenario Outline 的資料表，列出一組組測試資料。
如上例，Examples 區塊用來補充：
• 哪些輸入值
• 對應的預期結果

Gherkin 對實例化需求的幫助

接著，再看 Gherkin 對 SBE（Specification by Example） 的幫助是什麼，在 SBE 裡面，重點是用「例子」來清楚說明需求，而不是只用模糊的文字描述。

這時候，Gherkin 的作用是：

Gherkin 幫助 SBE 把「口語的範例」變成「可驗證的範例」。

那麼，如果沒有 Gherkin， SBE 還能做嗎？答案是：可以，但會比較「辛苦」且「易出錯」。

沒有 Gherkin 的時候，會遇到什麼問題？

那為什麼有時候 SBE 會「不強制用 Gherkin」？這是因為：
• 初期重點是釐清範例共識，不想一開始就讓「格式」干擾討論。
• 有些團隊覺得自然口語的範例（白話描述）比較親民。
• 真正上線時，再由專門的人把這些白話範例整理成 Gherkin。

Gherkin 不是強制必需，但如果要「持續合作、標準化驗收、自動化測試」，最終還是非常建議導入 Gherkin。